As network speeds increase, it becomes necessary to scale packet processing across multiple processors in a system. For receive processing, a feature called RSS (Receive Side Scaling) can distribute incoming packets across multiple processors in a system. RSS is a Microsoft® Windows® operating system (“OS”) technology that enables receive-processing to scale with the number of available computer processors by allowing the network load from a network controller to be balanced across multiple processors. RSS is described in “Scalable Networking: Eliminating the Receive Processing Bottleneck—Introducing RSS”, WinHEC (Windows Hardware Engineering Conference) 2004, Apr. 14, 2004 (hereinafter “the WinHEC Apr. 14, 2004 white paper”). It is also described in the Scalable Network Pack of the Network Driver Interface Specification (NDIS). NDIS describes a Microsoft Windows device driver that enables a single network controller, such as a NIC (network interface connection), to support multiple network protocols, or that enables multiple network controllers to support multiple network protocols. The current version of NDIS is NDIS 6.2, and is available from Microsoft® Corporation of Redmond, Wash. The subsequent version of NDIS, known as NDIS 6.2, available from Microsoft Corporation, is currently known as the “Scalable Networking Pack” for Windows Server 2003. With the RSS feature, the OS distributes the processing load for network traffic across multiple processors, cores, or hardware threads by maintaining an indirection table in the network device that maps flows to the processing unit.
On the network device side of packet flow processing, so-called “application targeted routing” (ATR) can be used to assign a network application to a specific MAC receive queue and processor core. Once the queue/core pair is assigned, ATR logic (residing in the MAC) can be used to track TCP/IP and/or UDP packet flows and post packets to the correct queue/core pair. However, an overloaded CPU or excessive packet offloading (for example, security offloading using IPSec or LinkSec protocols) may cause the receive queue to become overloaded. Conventional implementations of ATR do not account for load conditions on the MAC queues, and thus, an overloaded queue may result in packet loss and/or performance degradation.
Although the following Detailed Description will proceed with reference being made to illustrative embodiments, many alternatives, modifications, and variations thereof will be apparent to those skilled in the art.